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(54) TiUe: FILE DIRECTORY AND FILE NAVIGATION SYSTCM 



(57) Abstract 

The parallel virtual directory system (12) 
can extend the native file system (8) to provide 
a superior method for organizing a computer 
system's physical storage devices or locations. 
These can include hani disks and removable 
media or remote storage locations such as on 
Internet. Interceptor modules (2) can monitor 
all files or memory changes such as creation, 
writes and deletes to die native file system 
and can pass this information to the parallel 
virtual directory system. The parallel virtual 
directory system may be accessed through the 
native file system methods allowing users to 
view their file system as it existed at any point 
of time, including removable media that is no 
longer present in the system. The parallel 
virtual file system may be implemented using 
database technology allowing multiple views 
of the file system for an easier navigation 
through it. Further, a set of management 
processes (3) can run at the application level 
providing data management services such as 
backup, archiving, and recording. 
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FILE DIRECTORY AND FILE NAVIGATION SYSTEM 



S L TECHNICAL FIELD 

Generally, this invention relates to the field of enhanced organization of 
computer memory or file information and processes for managing the compute 
memoiy or file information at other than simply the application program levd. It may 
be used to overcome the usability barriers associated with the coupling and uncoupling 

10 of storage devices to a computer system. Specifically, the invention focuses on 

methods to gather information about hierarchical directories on physical file storage 
devices, the organization or manipulation of directory information into a global virtual 
directory system that can serve as a master directory for a user and processes that 
more effidently manage system data, regardless of application, based on information 

1 S obtained firom the virtual directory system 

IL BACKGROUND ART 

Over the years, the hierarcMcal directory systems that orgaiuze computer 
system data storage have been enhanced to make them more powerfid and easier for 
the end user to understand. Typically these unprovements have focused on a shift 

20 firom a tesctually oriented system to systems that are graphically oriented (for example, 
the shift fi-om a DOS type of directory listing to a graphical directory display of files as 
provided by products Gke Microsoft™ Windows™ for Workgroups ver. 3.11. This 
approach has been directed at increasing the user's understanding of the files available, 
but has not solved the problems caused by a ri^d directory structure nor the difficulty 

25 in locating files that have been removed firom the system or that are located in the maze 
of subdirectories. 



The hierarchical directory systems are intended to allow users to organize their 
data in ways that makes it easier for them to understand. This is done by creating 
directories, or folders, for specific classes of data such as word processing documents 
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or computer programs. Once a directoiy stnicture for the storage system is defined it 
becomes a tedious and di£Bcult task to reorganize the directory structure. Also, files 
of the same name cannot be stored within the same directory due to the common need 
for files to be differentiated by unique names even though it is common for users to 
5 desire to save copies of the same file at diflFerent points in the evolution of the file. For 
example, it would be very convenient if a writer could keep the same file name for an 
article and differentiate the various verdons of the article by the date and time of 
creation of each version rather than having to use minor variations on the original 
name. 

10 Perhaps surprisingly, the concept of flexibly organizing a hierarchial directory 

system has typically been utilized at only the application level; that is, it has been 
applied only in separately utilized programs which may act independently of other 
programs and not as one which applies to all programs. For instance, an application 
level process which addresses a user need for the ability to easily re-categorize, filter 

IS and search files is identified in U.S. Pat. No. 5,544,360 which describes an application 
program that aUows the user to filter and categorize the hierarchical directoiy systm 
to ease findmg files. The limitation of this invention is that it is an application 
program, or file manager, that can be used as a browser by the user but not directly 
accessed by other programs in the same manner that the native hierarchical directoiy 

20 system can be accessed. Hence, a second application program such as a word 
processor would not be able to utilize the sorted information — only the original 
application program could. Hence, there is a need for a configurable directory system 
that can be configured and made accessible at the operating system level such that all 
application programs can utilize the configured information. 

25 A common constraint of the traditional or conventioiud directory hierarchy is 

that it is oriented towards a hierarchical starting point of physical storage device, be it 
a hard disk, floppy disk, high capacity removable disk, tape, remote network device, or 
other storage media. Due to the coupling of a physical device to the directory 
hierarchy the user must organize their data in such a way that it fits the physical 

30 parameters of the selected storage medium. 



2 
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Various methods have been employed to try to decouple the physical nature of 
the storage device from the directory hierarchy. It is relatively common in netwoik 
environments to present a file server as a single storage entity even though it is 
composed of multiple hard disks (disclosed in U.S. Pat. No. 5,129,088). Or, a new file 
5 system can be created as in U.S. Pat. No. 5,333,3 15 to create a file system that is 
based purely on the hierarchy of the directory name space and not that of physical 
device. Agiun in the network setting, a method called hierarchical storage 
management is employed that has the primary purpose of fi-eeing up storage space on a 
physical device, such as a hard disk, by migrating files to another storage device, such 

10 as a tape drive, and leaving a place holder for the file so that it appears to the user that 
the file is still on primary storage. When the place holder file is accessed, the 
hierarchical management system retrieves the file from secondary storage (disclosed in 
U.S. Pat. No. 5,564,037). This same technique has been employed on a desktop 
computer using the desktop computer's local storage devices. These techniques allow 

IS the user to treat multiple storage devices of dissunilar nature as a single device. Sudi 
systems, however, only offer the user limited organizational control over the data. 
They do not offer the fiiU ability to manipulate the file system information as does the 
present invention and are often limited to merely migrating data to secondary storage 
devices. 

20 With the recent advent of low cost, high capacity removable storage, and the 

ability to store data remotely on the Internet, it is becoming increasingly difficult for 
the user to organize their data and to recall where thdr data is located. A 100 MB 
removable disk can store hundreds or thousands of data files. Likewise, a remote 
storage site on the Internet used for archiving might have thousands of a user's data 

25 files. Hence, the sheer volume of files that can exist on individual directories often 
makes it a very difficult task to find a stored file without traversing through hundreds 
of subdirectories. In the case of removable disks a user may have ten or more disks 
each with hundreds of files. Very clearly it becomes difficult to understand what file is 
stored where. Furthermore, the need for removable storage, or remote storage is 

30 increasing rapidly due to the easy availability of data on the Internet and the shift 

towards di^tized video information (e.g., movies stored as digital information that can 
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then be shown on your computer) which consumes great amounts of computer 
storage. Hence, there is an ever-increasmg need for a directory system that can keep 
track of all of these files on a single database that is accessible to an operating system. 

In addition, one characteristic that high capacity removable storage, for 
S example, has is that if the disk is removed fi-om the computer system or if the Internet 
connection is not active the user may not be able to determine which files are stored on 
the disconnected device until the disconnected de^ce is reconnected to the computer 
system. Essentially, these conventional directories are transient in nature since their 
information is lost to the system when the memory devices are disconnected or 
10 removed fi-om the system. Hence, there is a need for a directory system that maintains 
directory information that a user of a computer system (i.e., a computer operator) can 
utilize even when the storage media is not coupled to the computer system. 

Also, while some large computer systems have been able to enhance file 
directory capabilities, such capabilities have been sorely lackmg for unitary computer 
15 systems. Hence, the overwhelming majority of computer users who have standalone 
personal computers, which might also be connectable to a larger computer system, 
have had a need for a system that can provide the unique file management and tracking 
capabilities mentioned. 

Several key problems still exist with conventional directory structures. The 
20 first of these is the somewhat ri^d nature of the directory structure once such a 

structure is defined; which, for example requires that unique file names be used as the 
identifier within a directory. A second problem is the somewhat arbitrary 
organizational barrier that is presented by the coupling of physical storage devices and 
their related sizes to the hierarchical directory structures commonly used in computer 
2S storage; which for example, limits the number of files stored in a dkectory by the 
storage size of the physical storage size rather than permitting the user to irudude 
ad(fitional files whose file data would exceed the physical storage limitations of the 
phydcal storage device. A third problem is the transient nature of the hierarchical 
directory structure encountered when using removable or remote storage; which, for 
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sample, is often the result of the directoiy information for a storage medium only 
bdng present when the storage medium is connected to the system. These problems 
make it diflScult for both computer users and data management programs to organize 
and eflSciently work with a computer file system, if at all. 

While there have been a number of attempts to solve these problems, in general 
the attempts have failed to address them fi-om a perspective which present 
embodiments of the invention realized. Importantly, the present invention arrives at its 
solutions in manners which maintain compatibility and accessibility of a native file 
directoiy system. The new file system presented by several embodiments of the 
invention does not necessarily replace the native file system that the end user has 
selected; but rather, it is capable of working in concert with the native file system. In 
this manner, it can provide, for example, a file system for use by both the operating 
system of the computer system and application programs of the computer system. 

UL DISCLOSURE OF INVENTION 

The present invention includes a variety of aspects which may be selected in 
different combinations based upon the particular needs being addressed. The first 
aspect of the invention is that it in no way interferes with the current operation of the 
computer system's hierarchical directoiy structures or coupling to physical file storage 
devices. The end user may continue to use the file storage system in the same feshion 
to which they have become accustomed. In addition, application programs may 
continue to use the file storage system without modification. However, various 
components of the virtual du-ectory and navigation system can seamlessly link with the 
operating qrstem of the computer to provide a paraUel method for organizing, 
accessing and maintaining the computer system's storage. In addition, this cq)ability 
can be provided for a umtary computer system, such as a peraonal computer that can 
operate as a standalone unit. 

First, a set of active processes can be used to traverse a native file system's 
Rectory hierarchy and relay the directory information to the virtual directory system 
for organization and permanent storage (e.g., traversing the directoiy of the hard drive 
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on a personal computer and coping the directory information to the virtual directoiy 
system). Then, Interceptor modules can be used to link with the native file system's 
I/O procedures to passively intercept changes being made to the native file system as 
those changes occur. This might be done for all physical file storage devices of the 
5 computer system and regardless of the application program being run. The 

Interceptor modules then can relay the changes to the virtual directory system for 
organization and permanent storage. Using this method the native file system's 
hierarchical directory can be maintained at the same time that a parallel virtual 
directoiy system is built and updated. 

10 Another feature of the invention is that when a new piece of removable media 

is inserted into the computer system, or a remote storage site is connected to the 
computer system, the Interceptor modules can detect the coupling of newly mounted 
media to the system, actively read the directory structures of the mounted media, and 
relay the directory structures* information to the virtual directoiy system. Changes to 

IS the directoiy information of the mounted media can be detected and transfmed to the 
virtual directoiy system. 

An important benefit of the invention is that the virtual directoiy system also 
can connect to the native file ^stem of the computer system in such a way that the 
virtual directoiy system appears to be a plysical storage device. However, it has the 

20 advantage that if a user elected to the virtual directory system could represent all of the 
files contained on all of the physucal file storage devices connected to the computer 
system. Because the files stored on the physical storage devices can be represented in 
the virtual directoiy system and because the virtual directory system has among its 
characteristics the qualities of a relational database, the file information for the various 

25 files can be reoiganized, reconfigured, or searched easily. These features allow the 
user greater flexibility in how files are viewed and how the user finds data. 
Additionally, the database can overcome the requirement of unique file names, as 
imposed by traditional hierarchical directory systems. Multiple instances of a given file 
name can now be presented in the same directory with the uniqueness of the file data 

30 determined by the time the file was modified, the media it was stored on, or some other 
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file characteristic. 

When a user accesses a file via the virtual directoiy system the virtual directory 
system can retrieve the file fi-om the appropriate storage device via the Interceptor 
modules. If the user accesses through the virtual cUrectory system a file that is not on- 
line because the media is not mounted (i.e., connected to the conq)uter system) or the 
network connection is not active, the virtual directory system can automatically load 
the media if it can be done via mechanized means, prompt the user to assist in loading 
the required media, or even establish a connection to the service having the media. 
This removes the burden fi-om the user of needing to search multiple pieces of media to 
find the desired file. Similarly, when a user stores a file via the virtual directory 
system, the virtual directory system can store the file in a preselected storage location, 
prompt the user for storage location instructions, or assist, as mentioned above, in 
coupling the appropriate storage device to the computer system. 

Information management processes (JMPs) (3) can provide more eflScient 
execution of storage processes due to their understanding of the virtual directoiy 
system's unique information capabilities. These information management processes 
can be accomplished as application programs that communicate directly with the 
virtual directoiy system's database through a private inter&ce, such as the loctl 
inter&ce m the Microsoft™ Windows™ 95 system. The information management 
processes benefit fi-om their ability to share a common directory ^stem that spans all 
media types. For example, this means that an appUcation that specializes in disk 
grooming processes (removes files that have not been used for a long period of time) 
can verify that the system's backup program has copied one or more instances of the 
file to be groomed (removed from the hard disk) thereby ensuring that, should the usw 
decide to access the file in the fiiture, that a copy of the file is stored on removable 
media or a remote storage ^te. 

IV. BRIEF DESCBIFnON OF DRAWINGS 

Hgure 1 - Shov^ the intercormections that may be utilized between one type of 
apparatus according to the invention and the operating system. 
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Figure 2 - Shows an alternative embodiment of the virtual file directory system 
being used in conjuntion with a native file directory system. 

Figures - Shows a block diagram of the >^dows™9S as well as NT 
operating systems and and file system components which may be utilized. 

Figure 4 - Shows a flow diagram for use of a virtual directoiy system to obtain 
file data firom a native directoiy and pass the information to an application program. 

Figure S - Shows a sample flow diagram for a file open request that can be 
implemented by Windows 95. 

Figure 6 - Shows a sample flow diagram for a file close request that can be 
implemented by Windows 9S. 

Figure 7 - Shows a sample flow diagram for file hooked by an interceptor and 
the update of the virtual directoiy database pB) with file information, applicable for a 
Windows 95 environment. 

Figure 8 - Shows a sample flow diagram for monitoring mounting of media to a 
computer system and accessing file information stored on the storage media. 

Figure 9 • Shows an alternative sample flow diagram for monitoring mounting 
of a storage device to the computer system and tracking of the device to update a 
virtual directory system (VDS). 

Figure 10 - Shows a possible configuration of a virtual directory system and the 
program modules that can be used to implement the system as well as a virtual 
directoiy physical storage database. 

Figure 1 1 shows a flowchart for one possible method of updating a virtual file 
directory when files are saved to a native file directory. 

Figure 12 - Shows a flowchart for an alternative implementation of the 
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monitoring for the mounting of a storage media to the compute system, especially for 
a \^dows 95 implmentation. 

Figure 13 - Shows a possible configuration of an interceptor and the program 
modules that can be used to implement the interceptor's functions 

5 Figure 14 - Shows a sample flowdiart for an implementation of monitoring a 

file system open request, applicable for the Windows 95 environment. 

Figure IS * Shows a sample flowchart for an implementation of monitoring a 
file system write request, applicable for the Wmdows 95 environment. 

Figure 16 - Shows a sample database that shows the arrangement of file 
10 attribute fields containing file attribute data as well as additional storage space for 
fixture file attribute field data. 

Figure 17 - Shows an alternative file database entry with file attribute fields 
designated. 

Figure 18 - Shows a directory structure for a virtual directory divided into 
15 subdirectories. 

Figure 19 - Shows a directory structure for a virtual directory database 
configured to present three separate virtual directories. 

Figure 20 - Shows a typical hierarchical directory listing for a naUve file 
directory. 

20 Figure 21- Shows a database listing of file attribute information contained in 

configurable virtual directory database. 

Figure 22 - Shows a sample flowchart for reconfiguring a virtual directory 
database as might be implemented by an information management process. 

Figure 23 - Shows a sample flowchart for adding and deleting file attributes 

9 
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from a configurable file database of the virtual directory as well as a sort routine for 
configuring the virtual directory database. 

Figure 24 - Shows a sample flowchart for monitoring a file ^stem open 
request as might be implement^ in a Windows 95 environment. 

S Figure 25 - Shows how a sample flowchart of how an information management 

process (IMP) might reconfigure a ^rtual directory systenL 

Figure 26 shows one possible method for presenting information on devices to 
be monitored and designating devices to be monitored. 

V. BEST MODE FOR CARRYING OUT THE INVENTION 

10 As can be easily understood, the basic concepts of the present invention may be 

embodied in a variety of ways. It will be seen to involve both methods of handling and 
utilizing information as well as devices or programming to accomplish the appropriate 
results. In this patent, the techniques disclosed should be understood to encompass a 
variety of devices which may be used to achieve the results described. In many cases, 

IS the device elements are simply the natural result of implemendng the methods as 

intended and described. In addition, while some devices and programs are disclosed, it 
would be understood that these not only accomplish certain methods but also can be 
varied in a number of ways and accomplished by means recognized by those of 
ordinary sidll in the art. Importantly, as to all of the foregoing, all of these fiu:ets 

20 should be understood to be encompassed by this disclosure. 

As mentioned earlier, the present invention includes a variety of aspects which 
nmy be combined in different ways. Each of these aspects is first discussed separately. 
For exemplary purposes a preferred embodiment is described within the context of the 
Microsoft™ Wmdows™ 95 environment, however, sunilar embodiments are possible 
25 within other system environments as those of ordinary skill in the art would readily 
understand. As a starting point, one possible configuration of an embodiment of the 
invention can comprise an apparatus that presents to a user or operating system, for 

10 
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example, a native hierarchical directory, a virtual directory qrstem compriung a 
configurable, extensible database that can retain and oiganize file attribute information 
also stored in the native hierarchical directory, an interceptor apparatus that intercepts 
and relays information transmitted along the native file system's I/O inter&ce to the 
virtual directory system, and application programs that orchestrate information 
management processes on the database of the virtual directoiy. Embodiments of the 
invention also can include the methods by which the above mentioned apparatus 
interact. 

For purposes of this patent, the term "Presenting'' is intended to mean either 
displaying on a computer screen or pro\dding or maldng available for use, such as 
enabling an operating system and/or application program to use a file. Similarly, the 
term "native directory" is intended to mean the directory of a physical file storage 
device that is stored on the physical file storage device and facilitates access to the files 
stored on that physical file storage device (e.g., the native du-ectory of one's "C" hard 
drive would be the directory of files stored on the C: hard drive and which is stored on 
the C: hard drive). Also, a "virtual directory" is a directory of file information which 
can be presented to a computer operator, operating system, application program or 
some other aspect of a computer system as a directory that is representative of a 
physical file storage device(s); however, this virtual file directory is merely an apparent 
or "virtual" directory ^ce it can merely store file attribute information and is not 
actually affiliated with an actual physical storage device, as one would associate the 
afiSliation between one's "C: hard drive" on an IBM personal computer and the 
directory listing for that hard drive. However, it can be representative of a physical file 
storage device in that the operating system would conmiunicate with it in the same 
way that the operating would communicate with a directory for an actual file storage 
device (e.g, m issuing open/read/write delete requests to a file system driver for a 
storage device.) Finally, "file attribute information" is intended to mean properties of a 
file in defined categories, such as, for example, file name, type of data represented by 
the file (e.g., text file, executable file, WordPerfect 6.1 file, etc.) . file size, date and 
time of file creation or modification, date and time the file was accessed, programs 
which caused the file to be accessed, physical file storage device where file data for the 
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file is stored, parent directory on the physical file storage device in which the file is 
stored, child or subdirectory for the file, user defined descriptions for the file, etc. 

The virtual directory system can serve many fimctions and ^pear in different 
embodiments. Peiiiaps one of its most useful functions is the ability to store file 
S attribute information (16) about files stored on a native file directoiy system (8) and 
present that file information as if the files were stored in a distinct directory separate 
fi^om the native file directory system. 

The virtual du-ectory system is significant in that it can provide in a single 
database a configurable database of file information which act as links to the actual file 

10 data. No longer is a user constrained by the physical limits of a storage deface as to 
how many files can be listed in a single directory, as is the case with a single hard 
drive. Also, this database is configurable so that the directory can be manipulated into 
a new configuration and can make files available at an operating system level. This is a 
very significant feature, because it aUows the newly configured directory to be made 

15 available at the operating system level to application level programs. In this fashion, a 
user could configure the virtual global director/ with all of the user's word processing 
data files. Then, when the user wanted to find an old word processing data file, only 
the virtual directoiy would need to be accessed. This would save the user fi-om ha^ng 
to search through all of the various directories on the computer system until the 

20 desired word processing document was located. 

Similarly, the virtual directory system allows a user to store all of the files on 
the computer system in a single directory, if desired. This can be accomplished 
because the virtual directory system is only keeping track of file attribute information 
for particular files - not the file data itself Hence, with a database, the virtual 
25 directory system can easily keep track of the file attribute information for every file 

encountered in the computer system. Hence, the lortual cfirectory system can provide a 
single directory where all of the user's files are "virtually" stored and which can be 
eaaly searched rather than needing to search through the computer system's entire 
directory system. This benefit can easily be appreciated gjven the sheer volume of files 
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with which a computer system comes into contact over its lifetfane. For example, 
consider a computer system that has a floppy drive in which 100 floppies are used over 
its lifetime, a hard drive which stores three thousand files throughout 250 
subdirectories, five ZIP disks used on a ZIP drive which each store 1000 files, a tape 
S backup system which stores thousands more files, a CD ROM drive wluch uses 10 CD 
ROMs, each storing thousands of files, and an Internet connection which can access an 
Internet storage site where hundreds of thousands of files are stored. The search for a 
file that you know you encountered 5 years ago, but dont remember where, would be 
a Herculean task. Yet, with the virtual directory system, all of the file information for 
10 those thousands of files can appear in a single directory which can be easily searched. 

Furthermore, because the virtual directory system can be stored on a 
configurable database, the directory itself can be subdivided into additional virtual 
directories. Hence, a user can group all of the word processing applications into a 
single directory, all of the letters to relatives (which also are stored in the word 

15 processing directory) in a second directory, and all of the letters to Aunt Margaret 
(^ch are also stored in each of the first two directories) in a third directory. Then, 
each of these directories can be utilized by application programs as if they were 
directories of actual physical file storage devices, such as a local hard drive. The 
application programs which utilize the file information do not need to be able to 

20 configure the database of the virtual directory, rather the directoiy can be configured 
at the operating system level and th^efore it can appear as a physical storage device 
when called by the application level programs that need files represented by the virtual 
directory system. (It should be understood, however, that the virtual file directoiy 
system can be configured by an application level program. Therefore, the 

25 configuration can be accomplished quite easily when a new configuration is desired.) 
While prior application programs may have been able to search a native file directory 
system in order to create a desired grouping of files, these application programs did 
not make the groupings available for other application programs. For example, search 
of a directory system by a WordPerfect™ word processing program might have 

30 created a listing of files of all of a compan/s annual reports; however, that listing was 
not then accessible by a WORD™ word processing program as a separate directoiy. 
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Rather, the WORD™ program would have to repeat the search, as would the 
WordPerfect™ program when it was rdmplemented. Hence, the ability to configure 
the virtual file directory at the operating system levd is a significant feature of this 
embodiment of the invention. Others have apparent^ failed to appreciate the ability to 
accomplish this important feature or may have believed that it was not functionally 
implementable do to hardware constraints. However, with the development of new 
operating systems, the embodiments of the present invention will and are 
implementable to accomplish greatly improved performance over present rigidly 
structured directory systems. 

Importantly, the use of the virtual file directory system need not affect the 
existmg native file directory system. The native file directory system can still be used 
as usual by the computer system. Hence, there is no loss of compatibility of old 
application programs when a virtual directory system is implemented. Rather, the 
virtual directory system can enhance the computer's file system with its unique abilities, 
while not destroying the native file directory system which a user or application 
program might simply prefer to use. This is an important feature of the virtual file 
directory system as many prior attempts at creating enhanced file systems, especially 
extensible file systems, destroyed the compatibility of the native file directory. Hence, 
older programs which were not designed for the newer version lost compatibility. As 
those of ordinary skill in the art are well aware, compatibility of a new file system with 
existing application programs is perhaps the most important feature that a product 
must have. The virtual directory system can provide this, while others have apparently 
not been able to do so. 

With reference now to the figures, implementation of embodiments of the 
virtual file directory system can be seen. In Hgure 1. use of the Windows™ 95 System 
is utilized to demonstrate the architecture of the virtual file directory system. In Figure 
1, a native file directory system (8) can be seea In the Windows™ 95 environment, 
this native file directory system (8) can be comprised of the Installable File System 
(IFS) Manager, several file storage devices (4), and the device drivers for the various 
file storage devices. These file storage devices could be either a storage medium (44) 
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or the storage medium in combination >vith the device that couples the storage medium 
(44) to the computer system (1), such as a ZIP drive which couples a ZIP disk to the 
computer system or the storage medium itself. (A storage medium would be any 
device used to store file data, such as a floppy disk, a ZIP disk, a tape used in a tape 
5 drive, a compact disk (CD), a hard drive, an Internet storage device memory, etc.) In 
Windovra 95, the boxes labeled HD, ZIP and TAPE would be "file system drivers" for 
the storage media (44). Each storage medium (44) would typically comprise a 
directory of file attribute information (16) in a directory stmcture for the files stored 
on that storage medium. An interceptor (2) is shown between the IPS Manager and 

10 the other components of the native file directory system. The Interceptor will be 
discussed in more detail elsewhere. Figure 1 also shows a standard application 
program (5) (or similarly an Explorer) at the application level of the computer system 
(1). An operating system (20) can provide communication between the application 
program (S) and a native file directory of the native file directoiy ^stem (8), as well as 

15 with the virtual directoiy system. A typical operating system for Windows™ 95 can 
be seen in Figure 2. The operating systm m Hgure 2 is merely exemplary, as other 
operating systems may easily vary in thdr components and operability. 

A virtual file directory system (12) is shown in Figure 1 adjacent the native file 
directory system components. However, note that no physical file storage device is 

20 associated with the virtual directory for storage of data files, as is the case with the 

native file directory system. In this manner, the virtual directory system is ''virtual." It 
does not store actual file data. Rather, it points or directs one to the location where 
the file data is stored and can keep track of file attribute information in order to 
identify the file data. In contrast, the native file directory system is directly coupled to 

25 the physical file storage devices themselves, such that a call to the native file directory 
system is essentially directed at the physical storage device itself In Figure 1, the 
virtual directory system is shown configured into three virtual drives: a hard drive, a 
ZIP drive and a tape drive. In this fashion, the virtual directory file system might be 
representing the files stored on the hard drive, ZIP drive arid Tape drive shown as part 

30 of the native file directory system. Or, it might only be listing the word processing 

documents on each of those storage devices. It could even be representing other hard 
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disk, ZIP and tape drives not currently connected to the computer system. While the 
virtual directoiy system might only be configured as a single directoiy, the embodiment 
in Figure 1 shows the ZIP drive of the virtual directory system as a first >drtual 
directory, the hard drive as a second virtual directoiy (76) and the tape drive as a third 
S virtual directory. Furthermore, because the ZIP drive block is associated vdth 
coupling and presenting information for a removable storage media, it can be 
considered a means for presenting a directory of file mformation for a removable 
storage medium (72) 

The virtual directory system can be coupled to the interceptor (2) to allow the 

10 passage of data and commands between the interceptor and virtual directory system. 
Furthermore, the virtual directory system can be connected to the I/O system of the 
operating system (20) for the computer system (1). In Figure 1, this is shown as a 
coupling to the Installable File System Manager of Windows™ 95. Input/Output (I/O) 
requests in Window 95 are passed through this IFS Manager (6). Through this path 

15 or interface, the virtual file directory can receive commands fi'om an application 

program, operating system utility, or other program for a file represented on the virtual 
file directory system. Typical standard I/O commands could be open, read, write, 
close or delete conunands among others. While such conmiands would typically be 
supported by a standard I/O inter&ce of a computer system, oth^ commands might 

20 not. Hence, the virtual file directory system can also be connected to the application 
level of the computer system via a private interface (200). In Windows™ 9S, this 
private inter&ce can be accomplished by an lOCTL command module. The private 
interface allows an application program to communicate directiy with the virtual 
directory system v^thout having to go tiirough the standard I/O components. This 

25 permits, for example, an application level program to configure the database of the 
virtual directory system. Such configuration commands would not be recognized by 
the standard I/O interface, hence an error would typically occur. Hence the private 
interface allows unique commands which the application level program and the virtual 
directory system understand to be passed between the two. In addition, the private 

30 interface can be used to add information to the virtual directory system database. As 
described elsewhere, the virtual directory system can be extended with additional 
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information for each file record or collection of file attribute infomnation. Hence, as 
new categories of file attributes are created, the private interfiice allows a user to enter 
information about a file to the virtual file directory system database. 

In Figure 1, the lOCTL interface is shown between the application program 
S labeled IMP and the vir&al directory system. In addition, private mter&ces are shown 
between several other application programs at the application level and the virtual 
directory system. 

An additional connection (201) is shown in a dashed line between the virtual 
directory system and the I/O ^stem of the operating system. In Figure 1, the I/O 

10 system is shown in part as the Installable File System Manager. This connection or 
coupling shows that the virtual directory system might transfer data and conunands 
back up to the application level to input and output information through the I/O 
system. As a simple example, the virtual directory system when accessed for a file 
shown on its virtual directory listing can locate the actual physical storage location for 

IS the requested file and initiate its own request back through the installable file system. 
In this manner, the virtual directory system can request a file fi-om the C: drive, for 
example, then present it to a word processing program as actually having come fi-om 
the virtual file directory itself In this fashion, the virtual directory system can emulate 
or act as an actual physical storage device. 

20 Figure 2 shows an alternative block diagram of a computer system. Again, in 

Figure 2 a Windows™ 95 embodiment is used. Figure 2 demonstrates that the native 
directory file system components and the virtual directory system components all can 
be part of the Kernel level or Ring 0 level in Windows™ 95, whereas the application 
program can exist at the application level or Ring 3 level in Windows™ 95. For point 

25 of reference, Figure 3 shows a typical schematic of the Windows™ 95 and Windows 
NT operating system components. These include Windows™ NT I/O manager. 
Device Drivers, HAL, the Installable File System, File system drivers, Windows™ 95 
I/O subsystem, device drivers. Virtual Memory Manager/Services/Drivers. In addition, 
System VM, applications, system sendees, and MS DOS VMs are shown. 
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Figure 4 shows a method of utilizing one embodiment of the virtual directory 
^stem. In this embodiment, a typical computer system whidi has access to a plurality 
of storage de>dces can be used. For example the computer system may have access to 
a hard drive and a floppy drive or a hard drive and an Internet connection. Each of 
S these file storage devices could eaaly store many files. Furthermore, for each file 
stored on the file storage devices, there would be file attribute information listed for 
each file in a directory structure of that storage device. The file attribute information 
would describe the file and identify it fi-om other files. For example, an element name 
(PATENTl) an element type (.app), an element size (66,731), create date (07-29-97), 

10 and create time (06:00) might exist as part of the directory structure as file attribute 
information for that file. This can be understood fiirther by reference to Figure 17 , 
Figure 20 and Figure 27. As a first step of the process, the native directory of at least 
one of the physical file storage devices can be presented (400). Presenting is intended 
to mean not only the displaying of directory information on a computer screen to a 

15 user, but also the providing or making available for use of the information, such as 
enabling an operating system or application program to access or store a file. The 
native directory system's connection to the I/O procedures of the operating system 
allows it to be presented to the opting system and application programs, for 
example. In addition, a virtual directory system can be presented for use by an 

20 operating system (404). As noted earlier, this is a very unique fimction that others 
apparently &iled to achieve before the present embodiment of the invention. 
Furthermore, the virtual directory can be presented as representative of a pl^sical file 
storage device, such that the operating system can access through the virtual directory 
files represented by the file attribute information on the virtual directory. Such access 

25 can also be deemed to mean storage of new files through the virtual directory system 
such that the new files are represented by the newly stored file attribute information. 
The virtual directory can be presented as accessible to an application program as well 
as to the operating system. This can be accomplished, for example when the virtual 
directory system exists at the operating system or kernel level. 

30 Figure O demonstrates one embodiment of how the virtual file directory system 

can be used to retrieve or save a file. In this embodiment, a command fi'om application 
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level or operating system level can be received and accepted for a file presented on the 
^rtual file directory (408). In the A^indows™ 95 system, this command would be 
received by the virtual directory system file system driver firom the Installable File 
System M aiuiger Then, a means for retrieving a file (24) can be used to cause 
S retrieval of the file presented by the virtual file ^stem directory. Such a means for 
retrieval could be comprised of a program code module located in the virtual directory 
system. In one embodiment, it could be comprised of the code that accesses the 
appropriate storage media, conununicates the desired storage location of the file and 
receives the file fi-om the physical storage device. When a file request is received, the 

10 actual physical file storage location of the file can be retrieved fi^om the virtual 

directory system database. First, one can determine whether the file request is a read 
request (416). (For purposes of this example, it is assumed that a read request 
accomplishes both an open file and read file command as commonly understood by 
those of ordinaiy skill in the art. Similarly a write request is understood to mean write 

15 file and close file conmiands.) Then it can be determined whether the desired storage 
medium is connected to the computer system (420). If the medium is not mounted, 
one option is to mount the media automatically , via an automatic dialer for the 
Internet or automatic mechaiiical means for disk and tape devices (436), or in other 
mannas as those of ordinary skill in the art would readily understand. (Automatically 

20 is understood to mean that the computer opemtor does not need to asast in mounting 
the storage medium.) If the media cannot be connected automatically (432), such as a 
floppy disk under the control of a user, a message can be sent to an application level 
program, for example through the private interfece, to prompt the user via a pop-up 
screen to load the proper storage media (440). Then, the storage device can be polled 

25 to determine when the removable media is inserted and the newly inserted media can 
be checked to confirm that it is the desired media. With the media connected to the 
system, the desired file data can be retrieved to the virtual directoiy and passed back to 
the application program or operating system that requested it. Program code modules 
which make up part of the virtual directory system code or application programs caUed 

30 by the virtual directory system can be used as: means for determining whether a 
storage me^um is connected (28), means for prompting a computer user to mount 
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media (32), means for automatically mounting the storage medium (36), means for 
automatically establishing connection with a remote storage device (40). 

As shown in Figure 4 the virtual directoiy system can check to see if the file 
request is a file save request (444). If it is, the physical storage space can be accessed 
5 with the physical storage space descriptor element fi-om the virtual directoiy system 
database and the file data stored to the physical storage device (448). In addition, the 
virtual directoiy system can be updated with the file attribute information for the file m 
the ^rtual directoiy database (4S2). 

As additional examples of an implementation of the virtual directoiy system's 

10 use in receiving typical I/O commands fi^om operating system utilities or application 
programs, reference is made to Figure S and Figure 7 where flow diagrams for 
example Wmdows™ 95 based programs are shown. In Figure 5 a Windows™ 95 Rlc 
Open request firom the operating system is being processed. The virtual directoiy 
system resolves the storage media ID firom the file Path by scanning the virtual 

15 directory system database (500). If the selected media is not found in the database, an 
error message can be generated back to the user via an application program pop*up 
screen. If the media is found in the database, the physical storage devices arc then 
scanned to ensure the desired device is presently connected to the system (508). If the 
desired device is not connected, for example a ZIP disk missing fi-om a ZIP drive, the 

20 user can be notified of need for new disk (512) - fiirthermore a disk eject command 
could be used to eject an improper disk. If the incorrect media is connected in 
response, additional error signals can be generated (S 1 6). Once the appropriate 
media is installed, the virtual du*ectory system can itself issue a File Open request back 
through the Installable File System Manager of Windows™ 95 via the representative 

25 dashed line intei&ce (201) ^own in Figure 1 . This File Open Request is processed by 
the physical storage device Filesystem and unless an error occurs (522), a file handle is 
passed back through the Installable File System to the viitual directoiy system which is 
then saved by the virtual directory ^stem (5 1 8). The virtual directoiy system then 
assigns its own unique handle to the file, and sends that back to the application 

30 program or system utility which requested a file open of the virtual directoiy system 
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(524). 

Similarly, in Figure 6, an embodiment for Window 95 can be used to process a 
File Close request from the operating system. Upon receipt of the command, the 
unique file handle associated with the virtual directory system is used to look up the 
actual file handle for the physical file storage device. Then, the virtual directory 
system generates its own Close File request to the Installable File System with the 
actual file handle. This command is canied out by the native file directory (550). 
Then, upon completion the unique file handle associated with the virtual directory can 
be released (554) at which point the virtual directory system is finished with the Close 
File request (556). 

Interestingly, the virtual file directory system can exist as code that makes calls 
back into the I/O ^tem to access as storage medium, such as a local hard drive, 
where the database can actually be stored in database storage space (9) on the storage 
medium. In Windows™ 95, for example, the virtual directory upon receipt of a 
desired file would first make a call into the installable file system to request the virtual 
file directory database stored on a hard drive, for example. Then, the physical storage 
location of the desired file could be returned through the installable file system to the 
virtual directory system. Upon receipt of the physical directory storage location, the 
virtual directory system could implement its own file read command back to the 
installable file system, as described above. 

With a virtual du-ectory system, the user (e.g., a computer operator operating 
the computer system) has the ability to monitor the native file directory system for new 
information to add to the virtual directory system. Such new information might be 
new files saved to the native file system, revisions made to existing files on the native 
file ^stem, application programs accessing particular files, or essentially any change 
processed to the native file directory system. 

As shown in Figure 8, one possible embodiment of updating a virtual directory 
file system can be seen. First a native directory of storage devices can be presented 
(600). A virtual directory can also be presented (604). A monitoring step can be 
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implemented to monitor the input/output system (I/O) of the computer system with an 
interceptor for new media mounted to the system (608). This process is often referred 
to in the art as hooking the I/O system for the mounting of new media. If new media is 
detected (612), the disk label of the newly mounted media or other identifier for the 
S media used by the computer ^stem can be read (624) newly mounted media can be 
checked to see if it is known by the virtual directory system (616). If it is not known 
(old media) and the media is supposed to be monitored (648), then the virtual directory 
system can access the new storage medium (620), and copy the file attribute data for 
the directory structure to the virtual directory (628). If the media is known to the 

10 virtual directory, the virtual directory can determine whether the computer operator 
even cares about monitoring the media. Perhaps the media is a floppy disk where 
inconsequential files are stored and which the computer operator does not wish to 
monitor. If the media is not to be monitored (632), the virtual directory can simply 
return to monitoring for other newly mounted media or other tasks. If the newly 

IS mounted media is being monitored, the virtual directory system can access the storage 
medium (636), check or look for any changes to the file attributes in the du^ory 
structure as compared to such attributes in the virtual directory system database (640) 
and update the virtual directory system with any new information on the storage 
medium file structure by copying , for example, the new information to the virtual 

20 directory database (644). Program code modules wluch make up part of the virtual 
directory system code or application programs called by the virtual directory system 
can be used as: means for designating a particular storage medium (48), means for 
monitoring for a mountmg of a particular storage medium (52), means for accessing a 
mounted storage medium (56), means for retrieving information (60), and means for 

25 updating a virtual directory (64) shown in Figure 10. 

In addition to its use in monitoring for changes made by way of the addition of 
storage media to the computer system, the virtual directory system can also be used to 
monitor for changes made to the native file directory system in the form of changes 
made to existing files stored on the native directory system and the saving of new files 
30 to or deletion of existing files fi-om the native file directory system. In this mode of 
use, "changes" is intended to mean changes to any of the file attributes of an existing 
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file or the creation of a new file. Furthermore, the virtual directory system can act as a 
safety file backup program to store files that have been deleted firom the native file 
directory system, in case those deletions are later regretted. 

Figure L shows a flowchart of one possible method of updating the virtual 
S directory with new file information. A native file directory can be presented (300). 
Such a native file directory will typically be hierarchical in nature. A ''hierarchical 
directory is intended to mean a directory with a rigid structure of file attribute 
information, the structure of which cannot be reconfigured after its selection. For 
example, a hierarchical directory could be comprised of a nuniber of segment types 

10 arranged in a hierarchy, conmiencing with the root segment type; below the root 

segment type there is zero, one, or more segment types at the first level, with a similar 
structure below each of these first level types at the second level, and so on. Thus 
each segment type is dependent on a segment type at the immediately higher level. As 
an additional example, the typical structure of one's C: hard drive is envisioned as 

15 displaying drive name/directory/subdirectory/.../file name. Whereas a non*rigid 

hierarchy would allow presentation of this information in other manners, such as file 
name/subdirectory/... /directory/drive name. In addition, a virtual directory file system 
can be presented (304). Then, the I/O system of the computer system can be 
monitored by an Interceptor (2) for input/output commands or requests to the native 

20 file system (308). If the Interceptor detects such a request, the virtual directory system 
can check whether it wants to track the change — which might be determined based on 
the taiget storage device of the request. If the request is to be tracked, the request can 
be checked to see if it is a file save request (3 16). If it is, then the file attributes bdng 
passed through the interceptor to the native file system storage device can be captured 

25 (or copied) (320) and passed to the virtual file directory in order to update the virtual 
file (firectory with the file attribute information (324), e.g., by storage as a new record 
in the database. If the request is a file read request, the interceptor could cjq}ture the 
name of the application program that originates the file read request and then use that 
information to update the virtual directory system. Several of these fiinctions might 

30 occur fi-om the virtual directory system itself or might also be accomplished by the 
Interceptor independently. Figure 13, for example, indicates that the means for 
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monitoring changes made to the native directory system (68) could be comprised of a 
code module that is part of the Interceptor. Indeed, for some embodiments, the 
Interceptor could be considered a component of the virtual directory system. Figure 7 
shows a Windows 9S implementation of hooking file information and updating a 
5 database. Figure 9 and Figure 12 show alternative implementations of the file and 
media monitoring fimctions, for example, for a \^nd6ws 95 implementation. 

One application of the virtual directory system would allow it to be used as a 
backup system. In this manner when the virtual directory system was informed that a 
file was about to be deleted fi'om the native file directory system, the virtual directory 

10 system could actually copy the data fi'om the physical storage device where it was 
stored and copy it to a backup location (224). Then, the delete command could be 
completed. The file would appear as deleted from the native file directory, but would 
still exist in a backup directory on the virtual directory system. Then, at a later date if 
the user regretted deleting the file, the file could be retrieved by accessing this backup 

15 directory on the virtual directory system. The backup directory system would actually 
store the file on one of the physical storage devices — perhaps a tape backup drive. 
When a user wanted to empty the backup drive on the virtual directory system, the 
virtual directory system could be accessed and a delete comihand issued for the file. 
Such a delete command could then be implemented as explained earlier for the open 
20 file and close file conmiands. 

While the earlier discussion has mdicated that the virtual directory system can 
make calls firom the operating system or kernel level back to the application level, the 
virtual directory system could also be configured to make a direct cormection to 
physical storage devices. The virtual directory syst^ could implement the same 

25 interlaces provided by the file system driver components that support the physical 
storage devices. In this nuumer, the virtual directory system could be used by all 
application programs and operating system functions in a manner consistent with that 
of phyacal storage devices. As those of ordinary sidll in the art would readily 
understand, the virtual directory system may provide fiinctions such as open volume, 

30 read data, write data, seek, delete volume, rename volume among others, in a manner 
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that is consistent with physical storage devices for the given native file ^stem. The 
virtual directory system can also pro\dde the common attributes associated with a 
hierarchical directory system such as the parent/cluld/sibling relationships associated 
with physical storage devices, directories, sub-directories and files. This implies that 
the virtual directory system may also support find first and find next fimctions 
associated with traversing hierarchical directory systems. Figure 17 shows a possible 
record structure that the virtual directory system may implement to provide the 
services that are expected by the native file system. As discussed earlier, when a user 
does request access to a file that they have selected fi-om the virtual directory system 
the virtual directory system may return a file handle in response to the file open 
command. However, before the file handle is returned for the user request, the virtual 
directory system may need to call or send a message to the interceptor module so that 
the requested file can then be opened on the physical storage device that contains the 
actual data. This sequence of events may be observed to ensure the file is indeed 
accessible on the target device and to take the necessary steps to load the appropriate 
media should it be off-line. Once the file handle is returned, the virtual directoiy 
system and the mterceptor may then become a pass through device between the 
phy^cal storage device and the various requests of the user. 

The implementation of the virtual directory system should be straightforward 
once the basic principles as explained above are understood. For example, the virtual 
directory system may also be implemented as a file system driver or drivers. It may 
incorporate a database comprised of all or some portion of the file system name space 
desCTiptors. When used as a virtual access location, it may serve as a control for the 
interceptor. In this mode the global system may cause the interceptor to respond to 
standard file system commands to initiate actions involving a physical storage device. 
For example, if the virtual directory system received an "open file" command, it could 
in turn (via the Interceptor's loctl or other such interface) make the interceptor issue 
the command to achieve the action. As one of ordinary skill in the art could easily 
implement without undue experimentation, since the virtual directory system could 
emulate a physical storage device at the driver level, any application could perceive it 
as an actual storage device and could program the overall system to fimction as usual. 
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Further, since the virtual directory system's information could be configured as a 
database system, access and utilization of the information of the virtual directory 
system could be achieved through well-known database programming techniques 
without undue experimentation. 

5 As noted earlier, some of the capabilities of this paaralld virtual directory 

qrstem which can provide parallel information of a native directory system aspect of 

i 

the invention may include prpviding the ability to connect to the native operatmg 
system's file system interfacejin a manner ^milar to a block device, such as a hard disk. 
It may allow read/write access to all virtual files. In addition the ^stem may utilize 

10 database technology to allow gross manipulation of the information in a gross manner 
to permit reorganization, recharacterization and other appropriate handling or 
presentation of the information. It may also present to the native operating system a 
directory structure that is composed of entries gathered via the Interceptor module(s), 
and may present to the system user a virtual file ^stem representative of all files 

1 5 contained within the native file systems. The virtual directory system may provide a 
secondary interface so that application level programs may configure its database so 
that multiple views of the global system may be created. Through an ability to present 
multiple views, it may export those views to the operating system's file ^stem 
interface in such a way that the views are presented to the end user as discrete logical 

20 devices via the native file browsing mechanisms. In utilizing its database c^abilities, 
the global system may organize lists of files that meet predefined, or user defined 
criteria and may provide these lists of files on demand to Information Management 
Process^ (IMPs) to more eflBciently carry out data management processes. It may 
also allow the end user to access any file in the computer system, either directly 

25 through the native file system, or indirectly through the parallel vutual directory 
system. 

Furthermore a goal of the system may be to organize the end user's data and to 
make it easier to manage the data for backup, archiving or other data management 
processes. The heart of the ^stem m this regard could be the Parallel Virtual directory 
30 system. This system may be a database that could be used to track the state of eveiy 
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file in the system. This could be accomplished by accessing an installable file system 
(such as the Windows™ 95 Installable File System) to monitor changes to any file in 
the system. This could include data on removable media as well as the hard disk. 

One of the advantages with a design such as the global system could be the use 
S of a persistent memory. V/iih the popularity of Zip drives and DVD drives, end users 
could have a huge amount of data on disks that aren^t mounted in the system, so, as &r 
as the normal file system is concerned these files don't exist. With a persistent file 
system such as might be configured, the computer system could remember that the files 
exist and on which piece of media it is located. In this fashion, an md user could 
10 always find any file even if the disk were not loaded. H'they requested the file through 
a persistent system, then the invention could act to tell them to mount the required 
piece of media. This same process can work for files on tape or that you might store 
at an Internet storage site. 

It should be noted that many of the functions and apparatus demonstrated in 
IS the figures in this patent may be interchanged to suit a particular embodiment of the 
invention. 

As noted above, the virtual directory system can utilize an interceptor 
apparatus to detect changes that occur in the native file directory. Such changes might 
involve the connection of new media to the computer system, the input and output 
20 commands for files stored on the native file system, as well as many others, such as the 
application program originating a request for a file. 

In one embodiment of the invention, the interceptor can be inserted between 
the operating system interface to the physical storage devices and the physical storage 
devices themselves. This might be visualized as a single interceptor (2) module as 
25 shown in Figure 1 or as separate interceptor modules (2) for each storage device as 
shown in Figure 2. The interceptor module can be programming code that receives an 
Input/Output command fi^om the I/O interface and determines fi-om that command 
whether the interceptor (or its master, such as the virtual directory system) is 
interested in the information being input to or output fi'om the native file directory. 
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The Interceptor (2) might even be used to initiate its own command to check system 
flags, interrupts, or system status, when the 1/0 command is recdved. In this manner, 
it could be used as an intelligence gathering or error checking device for a system. If 
the interceptor is interested in a command, it can then relay the information to its 
master, such as a second file directory system (88) like the virtual directory system. 
Such information might include the name of the application program that sent a 
command or request, or file attribute information (16) for a file. This information 
could then be stored in the second file system. As shown in Figure 13, such processes 
could be accomplished by programming code that acts as: means for monitoring 
input/output (108), means for relaying intercepted information (96), and means for 
capturing application program name (124). 

Additionally, or as a separate embodiment of the invention, the Interceptor (2) 
could be used to monitor for the attachment of storage media that was either 
reconnected to the computer system or which was newly connected to the computer 
system. If there were such a desire, the Interceptor could even be used to monitor 
when media was removed firom the computer system. This process can be understood 
by reference to Figure 8 which was discussed earlier. For example, it can be used to 
check the new media for any new information that should be added to the virtual 
directory system. TWs might be accomplished by accessing the directory structure of 
the new media, scarming for any new information ^.e. traversing and comparing to the 
data in the second file system) and relaying the data. Program code modules as shown 
in Figure 13 could be used to accomplish the means for scanning (104), means for 
monitoring I/O requests (108), means for copying file path information (1 12), means 
for relaying information (96), and means for checking time stamp information (120). 

Figure 14, Figure IS, and Figure 24 demonstrate some ways in which an 
Interceptor module can be utilized in the \Wndows™ 95 environment In Figure 14, a 
procedure for monitoring of File System Open requests is shovm. Rrst, the application 
program makes a Ring 3 (an application level request in M^ndows™ 95) request to 
open a file (700). Then, the interceptor receives the request (704) as it is located as 
shown in Figure 2 between the Installable File System Manager and the Filesystem 
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Device Driver. (The use of the interceptor in this manner is often referred to as 
hooking the I/O. ) The interceptor can then associate a state with tMs request (708) 
and either open an existing file or create a new file. If a new file is bmg created, the 
file information sent with the open request can be inserted in the database (712). In 
5 Figure 14, a procedure for monitoring of a File System Write request is shown. The 
application program makes a Ring 3 write request (750) and the interceptor receives 
the request via the BPS Manager hook (754). Then a save state is made indicating the 
file has changed (758). When the close request is received, the state is examined and 
the file information is upcjlated in the virtual directory system database. In Figure 24, a 
10 procedure for monitoring a File System Delete request is shown. The application 
program makes a Ring 3 File Delete request (775). The Interceptor (2) receives the 
request fi-om the IFS Manager hook (780). The file is then deleted fi-om the database 
(784). However, as noted earlier, the file can be backed up on a virtual directoiy 
system, as an alternative prior to deletion. 

15 For exemplary purposes, alternative configurations of the interceptor module 

could be used. For ecample, the interceptor apparatus may be composed of several 
modules as noted earlier. The interceptor apparatus may reside at the application and 
file system inter&ce. Its purpose can be to intercept file open, read, write and ddete 
requests fi-om application programs and system utilities. When these requests are 

20 intercepted, the file path information may be copied fi-om the request and reUiyed along 
with the physical device target information via procedure call or system message to the 
virtual directoiy system. Often, it can be critical that the request is intercepted at a 
level where the user defined names are present and before the file system translates the 
request into an internal file handle. This can be necessary so that the user defined 

25 names can be stored and later presented when the virtual directory system is accessed. 

As another example, the interceptor module may reside between the installable 
file system and the file s^em driver. The purpose of tUs module may be to detect 
when media is changed in a removable storage device. This may be done by pollmg 
30 the device or detecting media change messages firom the file system driver, as well as 
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any other means available. This module then may mimic system calls nonnally 
inq)lemented by the installable file system to extract directoiy information from the 
newly inserted media. This module may read the media label and may query the virtual 
directoiy system to see if data regarding this media has been previously recorded 
5 within the virtual directoiy system. If the directory information contains time stamp 
information this may be checked against the last recorded information for the particular 
media and if the time stamp indicates that the media has not been altered since the last 
insertion then the step of actively extracting the directory information from the disk 
may be omitted. 

10 The interceptor modules may be used to extract directoiy information from the 

physical storage devices in a manner which is transparent to both the user and to even 
existing application programs. An interceptor module can be used to provide read and 
write or other such access to the file data contained by the physical storage devices. 
This fimction can be necessary to allow the virtual directory system to emulate a 

15 physical storage device. When the user or application programs request to read or 
write file data via the virtual directory system, the virtual directory system ideally may 
provide a virtual connection to the physical storage device that the data is located oa 
The interceptor module can emulate, in the case of Windows™ 95, fimcdons provided 
by the installable file system. The module can implement the protocols for read/write 

20 operations to the file system driver associated with the target physical device. In most 
operating systems this interceptor module can be used in lieu of the standard file 
system interface due to reentrancy problems commonly encountered when operating 
^stem driver level components attempt to call into the application level interface of 
the operating system. Naturally, the system could automatically dlt&r its agnals to 

25 mimic or emulate the type of storage device expected to be operated and thus act 
without any apparent impact on the user or those applications utilizing such signals. 

Some of the capabilities of the interceptor aspect of the invention may include 
providing that the Interceptor module(s) may capture changes to files on a plurality of 
fixed, removable or remote storage devices and relay the names of the files changed 
30 and the nature of the file changes to the virtual directoiy system or the like. The 
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Intercq>tor moduIe(s) may also detect the type of application program that originates 
the file changes and relay the application program type along with file names and types 
of changes. Similarly, the Interceptor module(s) may identify the type of file data 
stream and extract class unique file metadata and relay tMs information to the system. 
5 It may allow the system to extract a data stream fi-om a plurality of fixed, removable or 
rmote storage devices and allow the system to write a data stream to a plurality of 
fixed, removable or remote storage devices, and reflecting these changes in both the 
directory structure provided by the virtual directory system and the direaory structure 
provided by the native file system. It may also detect when new removable media has 
10 been mounted and without user intervention relay the directory on the media to the 
virtual directory system and update the system to the current state of the removable 
media. 

As one additional example, the Interceptor may be a series of routines which 
achieve the desired fimctions. These could include a "means for sensing a change 

15 event" or a sensor which might be any device, wiring, or program subroutine that 

monitored (via a monitor) the various signals present and constantly tested them to see 
if they were of a character that indicated a change or other appropriate event might be 
occurring. Thus the means, might be a change sense routine or even hardwired change 
sensor circuitry. As those of ordinary skill in the art would readily understand, this 

20 change event sense routine might use the loctl interface (for \^mdows™ 95) or other 
such interface to achieve its goal. Once a change event occurred, the change event 
sensor or change event sense routine might activate a data capture routine which could 
then provide input to a data store means or routine. This data store routine might 
access an allocated memory on any one of the memory means of the computer. 

25 Preferably the memory element accessed would be a non-removable type of memory 
(such as the hard drive) which would always be available. Similar^ the interceptor or 
intercept routine could provide a response or signal capability to allow the application 
or user to obtain the desired item. This capability might consist of a signal generator 
or signal generation routine as those of ordinary skill in the art would readily 

30 understand. 
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The native file system usually provides access to various physical devices used 
for storage of data by the computer system. Application level programs usually rely on 
a consistent inter&ce to file data within the context of a ^ven operating system. In 
turn, the native file system of the operating system may expect a consistent set of 
5 services to be provided by the file system drivers for the various physical storage 
devices connected to the computer system. Figure 2 shows a block diagram of the 
Windows™ 95 operating system and the elements that make up its current native file 
system. The role of the various interceptor apparatus described earlier can be to 
capture or inject data at the various levels of the native file system architecture for the 
10 purpose of monitoring or providing access to the data stored on the physical storage 
devices. The interceptor apparatus can provide these fimctions for the benefit of the 
virtual directory system. 

The Interceptor might be created as a programmed module which serves as a 
file system driver or drivers. It might insert between the installable file system and the 
15 file system driver of the target physical storage device as a person of ordinary skill in 
the art could readily understand and implement using standard knowledge, textbooks, 
or routines. It might thus receive all standard file system messages intended for the 
physical storage devices, messages of interest to the virtual directory system, as well as 
those of interest to the target physical storage device. 

20 As noted earlier, the virtual directory system can utilize a configurable database 

(128) for storing file attribute data or information (16) about particular files stored on 
a native hierarchical directory system. A collection of file attribute data for a single file 
can be considered a set of file attribute data or a file record. As a matt^ of course, the 
database (128) will have a mmimum number of file attribute fields (164) when it is first 

25 created. As indicated by example in Figure 16, within each file attribute field for a fil^ 
file attribute information (16) can be stored. Such information would relate to the file 
^ch it rq)resents and also rdate to the parameters used to define that particular 
field. 

Because the file information is stored in a relational database rather than in a 
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rigidly Structured storage system, it may easily be reconfigured by normal database 
operations. For example, if a new file attributes are desired to be added to describe a 
file, such an additional file attribute fields (172) can be added to the database in order 
to eTctend the information contained by the database to describe a file. Within the 
S additional file attribute fields, additional file attribute information (176) could be 
added. A means for adding a new file attribute to the configurable database (180) 
could be used to accomplish this and would typically be comprised of database code 
which operated on the database. Similarly, a means for deleting a file attribute field 
(192) could be used to delete a file attribute field. Similarly, a means for selecting a 
10 file attribute field (184) and a means for sorting the configurable database (188) could 
be unplemented through program code to accomplish those functions and configure 
the database in a new arrangement. This versatility would then allow the database 
information to be rearranged, grouped or configured based on the user's conunands. 

For example a typical DOS directory is shown in Figure 20. This directory is 
1 5 shown as an extended version in Figure 2 1 . An extended directory of information in 
the virtual directory file system designated as H: is shown in Figure 21. This extended 
system has added a description field and three backup fields where files can be backed 
up when they are changed. Furthermore, the extended directory demonstrates that 
files can exist with the same file name in the same directory. The database can 
20 distinguish such files based on other file attributes such as time and date of creation or 
file size if it were configured to do so. Because the virtual database is separate firom 
the native file directory, it does not destroy the tuttive file directory system. Rather, 
the native directory system can be accessed as always; while the virtual du-ectory file 
database can permit more advanced file access. 

25 WitMn the context of a hierarchical directory ^stem the parent/child/sibling 

rdationships can be &irly rigidly defined.- Both out of necessity, and the desire to 
provide organizational benefits, the virtual directoiy system can provide dynamic 
methods for definuig parent/child/sibling relationships. For example, each record 
noted in Figure 17 cont^hs an entry for a physical storage device, therefore a given 

30 instance of a hierarchical directory that the virtual directory system presents to the 
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native file system might be one that exactly parallels the data presently stored on a 
^ven physical storage device. That is, the starting point of the hierarchy might be that 
of physical storage device^ so the directory tree would start with the ''c:" hard disk for 
example. However, in the case of the virtual directoiy system the physical storage 
5 device might be used only as a uniqueness identifier at the bottom of the hierarchical 
directory tree. As a result, the virtual directory system may need to be adaptable in 
how the hierarclucal tree is presented to the native file system. In order to overcome 
any uniqueness barrier which may be presented by the hierarchical directoiy system, 
the \drtual directory system may actually present the file entity as a pseudo directory 
10 entry to the native file system, this is so that the date/time combination or the physical 
storage device nught be treated as the file instance for the purpose of uniqueness. 

As another example, a hierarchical directory path might be expressed as 
"c:\document\patentapp.doc". Within the native file system patentapp.doc is the entity 
that is accessed for the data. Imagine within the virtual directory system that it 

IS contains the path ''c:\document\patentapp.doc" and it has a time and date associated 
vAih it of 1 1/1/96 12:01 p.m., just as it exists on the c: storage device. In this case, the 
virtual directory system may also have two other entries for this file because the user 
wished to ensure that there were multiple copies of this important document. The 
virtual directory system may also contain entries for 

20 *'zipdiskl\document\patentapp.doc" with a date associated with it of 1 0^ 1/96 09:00 
a.m., and another instance of '':dpdisk2\document\patentapp.doc" with a date of 
1 1/1/96 12:01 p.m.. If the user wished to see all mstances of .doc files the virtual 
directory system could then provide three unique paths to the file consisting of 
**\document\patentapp.doc\l 1/1/96 12:01 p.m,\c:", "\document\patentapp.doc\l 1/1/96 

25 12:01 p.m.\zipdisk2" and finally ''document\patentapp.doc\10/3 1/96 09:00 
a.m.\zipdisk:l**. Methods for converting time/date representations to suit the 
requirements for the native file systems path can, of course, also be tsulored as needed. 
An unportant feature in this regard may be the virtual directory system's ability to 
dynamically resolve the uniqueness requirement of a hierarchical directory by altering 

30 the directory element attributes that are presented to the native file system during the 
find first, find next directory query sequence. 
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As mentioned, since the global system could be configured as a database it 
could present to the user many different "disks" just by configuring a different view of 
the system. A user could look at files in the system at a certain pomt in time, or with a 
particular name, or files that you have deleted fi-om the hard disk but are stored on 
removable media. This can be seen in comparing Figure 27, Figure 18 and Figure 19. 
In Figure 27, a directory configuration which displays all of the files in the virtual 
directory database as one directory is shown. In Figure 1 8, subdirectories have been 
introduced to group files having common themes: patent applications, digital movie 
data, and business reports. In Figure 19, three different virtual directories are 
presented. Furthermore, some of the files are presented in diffwent virtual directories 
at the same time. For example, the one file mth the filename Patents .app is presented 
to the computer system in virtual directories H:, I: and J: simultaneously. 

The use of a database to store directory information provides unique 
opportunities for a computer system in managing that database. While a standard I/O 
interface will typically support I/O commands between a virtual directory system and a 
computer system's I/O system, commands directed to configuring the virtual directory 
database or adding information will likely not be supported. Such commands can be 
originated by programs known as Information Management Processes (IMPS). For 
example, in Windows™ 95, commands such as read, write, delete, open and close can 
be passed by the Installable File System Manager to the Virtual Directory Hlesystem. 
However, a command to configure the virtual directory database, would not be 
supported by the File System Manager. Hence, a private interfiice is necessary for 
conununication of such unique commands firom an application program used to 
configure the virtual file directory system to the virtual directory file system itself The 
private inter&ce can then transfer the unique cormnand to the virtual directory system. 
Such an interface can be usefiil to not only configure the database, but also to input file 
attribute information such as the extended field information shown in Figure 21. In the 
Windows™ 95 environment, one such private interface can be accomplished through 
use of the Wmdows™ 95 lOCTL command. 

An example of a method used to configure a virtual directory file system is 
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shown in Figure 22. As a precursor, information from the native file directory can be 
input to a virtual file directory. (800). Not all of the information need be input to the 
virtual directory, however. The directory information from the native file directory can 
be stored on a database of the virtual file directory (804). A private inter&ce can then 
S be established between the virtual directory file system and an application program. 
Through this interface, a command can be issued to the database (808). If the 
command indicates that the database is to be reconfigured (812), the virtual file 
directory can then receive database sort criteria from the application program (816). 
From the sort criteria, a filter (208) can be created (820). The database can then use 

10 the filter to sort the database (820). File attribute fields might be elimmated or 

arranged in different orders. Furthermore, subsequent sorts can establish the <latabage 
into a variety of dififerent combinations or groupings. Hence, the configuration 
command sequences could group a single virtual directory into multiple virtual 
directories, such as a first virtual directory, a second virtual directory (76) and a third 

IS virtual directory. Such is the embodiment in Figure 1 where three virtual directories 
are shown representing parallel configurations of the hard drive, ZIP drive and Tape 
drive of the native file system. As noted earlier, such configurations are unique torn 
prior attempts in that the configuration can be accomplished by an application program 
and then retained for later use by dther the operating system or a different application 

20 level program. When the virtual directory system operates on the arrangement of the 
file attribute information, for example the file path information, it can essentially 
reconfigure the hierarchy of the virtual database. For example, if the database is sorted 
so that instead of the file name being the first file attribute, but instead the file 
subdirectory is the first file attribute, the hierarchy has been redefined. The program 

25 code in the program that issues sorting commands to the virtual file directory can 

constitute a means for sorting the virtual file directory (204). Similarly, program code 
which issues reconfiguration commands can be a means for reconfiguring the virtual 
file directory (216). Program code which issues commands to redefine the hierarchy of 
the virtual file directory could constitute a means for redefining the hierarchy of the 

30 virtual file directory (220). 

The flowchart in Figure 22 goes on to show how an Information Management 
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Process can also manage the configurable file database. For example, if a backup 
command is received (824), the virtual file directory ^stem can recdve from the 
application program input on the identity of files to backup and locations of where to 
store those files (828). This type ofinformation can be seen in Figure 21. Then, the 
5 virtual file directory system can monitor for changes to selected files (832). If changes 
are detected, for example by an interceptor, the revisions can be backed up to the 
designated drives (836), i.e. some sort of storage medium for backing up files (224) 
which could essentially be any type of computer memory. Referring to Figure 21, if a 
change is made to the one file designated as "command.com", the revisions could be 
10 backed up on the C: drive, the Didrive and the E: drive. Such back ups might be 
accomplished from the application level or from the operating system level. 

Figure N shows an additional example of configuring a database. As a 
precursor, an accessible native file directoiy is established so that it can be accessed by 
application programs (850). An accessible native file directory is intended to mean a 

15 directory which can be accessed, for example, by an operating system or an application 
program. In addition, a virtual file directoiy database is configured to have a first 
maximum number of file attribute fields (853). If it is determined that a file attribute is 
to be added to the database (856) and if the file attribute field does not exist, 
formatting du-ections can be passed to the database and the new file attribute field 

20 created. Then, a file can be designated by existing file attribute information (859), the 
file attribute field selected (862) and the new auribute field infonnation passed to the 
virtual directory via the private inter&ce. The virtual directory file system can then be 
presented to the computer ^stem (865) for fiuther use, whUe still maintaining the 
ability of the native file system to interact with the computer system. 

25 If a delete file attribute command is detected (868), a file attribute field can be 

selected (designated) and passed to the virtual directory system (871). Then the virtual 
directoiy system can delete the file attribute field (874) and present the database 
(877). If a sort the file database command is received (880), a selected file attribute 
field can be passed to the virtual file directory system (891) and a sort carried out on 

30 the database (894). As a subsequent step, the sorted files could also be grouped into a 
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first virtual directoiy (897) and the directory presented for use by the compute 
system. Similarly, a subsequent sort could be conducted upon a subsequent sort 
command (901). A second file attribute field could be indicated (903), the virtual file 
directory database sorted based on that attribute field (90S), the second sort grouped 
5 into a second virtual directory (907) and the first and second virtual directories 
presented to the computer system. 

Figure Y illustrates a Windows™ 95 embodiment where an Information 
Management Process application program configures the virtual directory file system 
database. First, the application program forms a filter for the database object and an 
10 application program interfile referenced as dll api (950), The DII api then perfonns a 
DevicelOControl to the virtual file directory Filesystem Driver (954). At which point 
the Filesystem Driver (7) saves the filter for the database object mto the database 
(958). 

As another example of use of an information management process application 
15 program to manage the virtual directoiy file system database, Figure 26 shows a 
flowchart for selecting storage media to be monitored. As before, a native file 
directoiy system can be presented (975). Also, a virtual directory file system can be 
presented (978). A listing of storage media being monitored (e.g., when rcNdsions are 
made to the storage media the revisions are noted on the virtual directory system) is 
20 presented to the user on the user's computer screen (98 1). Furthermore, a listing of 
storage media not being monitored can be presented on the user's screen as well (984). 
And a listing of storage media available to be monitored can be presented (987). Then 
a computer operator can designate which storage media should or should not be 
monitored (990) and those results can be passed to the virtual file directoiy system 
25 which can either implement the monitoring control in conjunction v^th an into^eptor 
or pass the information to the interceptor which accomplishes the monitoring itself 
until it needs to update the virtual directory system. 

The virtual directory system may provide the private inter&ce as a mechanism 
for configuration by the information management processes and as a means for the 
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information processes to retract information not readily supported by the native file 
^stem interface. 

The ability to configure the virtual directory system via the loctl or other such 
interface, or ^milar pass through mechanism, may be necessary to provide the multiple 
5 view attribute of the virtual directory system. Furthermore, the virtual directory 

system can report to the native file system that it is not just one storage device but any 
number of devices. It may be desirable that the virtual directory system reports as a 
"device 1" and provides a view of all files on all media. As "device T it may provide a 
view of just data on removable media. As "device 3" it may provide a view of the 

10 primary physical storage device at a user definable point in time. All of these data 
views can be configured dynamically via the loctl or other such interfece. In the case 
of "device 3" the controlling information management process may send a message to 
the virtual directory system setting the primary physical storage device as a search 
constraint when the virtual directory system responds to the find first/find next queries. 

IS Additionally, the information management process can send a message setting the 
search constraint of only files created and modified prior to a user definable date. In 
this case the information management process might be an application that allows the 
user to select a physical storage device and a calendar date. As the user changes these 
parameters the virtual directory system may receive the corresponding messages and 

20 dynamically reconfigure itself to search for files that meet the criteria. In this manner 
the user can easily modify how they view the q^tem data and more importantly how 
all application programs view the data. TMs unique fimctionality is designed to 
augment that available in most standard operating systems. 

Information management processes may be apparatus that implement different 
25 storage management strategies or may be methods. As discussed above a simple 

information management process can be used to simply configure views of the virtual 
directory system. A more complex example might be the in^lementation of a distal 
video information management process. The video process might be provided by a 
cable TV or Satellite TV vendor for recording programming via the computer systems 
30 storage device. For example, two classes of data might be downloaded by the vendor, 
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the first being movies that the subscriber cashes to rent or buy which must be recorded 
on a high capacity device such as a tape drive. The second class of data may be ^ort 
commercial programming that the vendor wishes to play whenever the subscriber 
begins to watch a movie or whenever a movie ends. The commercial programming 
S then may require fast access speed to the individual commercial segments that is not 
easily provided by tape. The video process could then implement a method by which it 
could load the commercial segment to available hard disk space or high capacity 
removable disks that can ensure the access characteristics that are required. Further, 
after the commercials have been played the number of times that the vendor had 

10 defined at download time, then the video process could even erase these segments 
without user intervention. The video information management processes could also 
assist in organizing data for the user. When the video process records the movie it 
could send a message to the virtual directory system to create a pseudo device that 
could be exclusively for movies, thus providing the user with an easy means of finding 

IS movies. 

Some of the capabilities of the Information Management Process aspect of the 
invention may include providing an IMP that may connect to a virtual directory system 
via a secondary communications path provided by the operating system or via a private 
conununications path for the purpose of configuring the system for data management 

20 unique processes. It may allow end users to configure the system for the purpose of 
viewing file du-ectory information in a better organized and efficient manner. The 
results of this data organization may be viewable through any application capable of 
accessing the system through the operating system or othenvise. The IMP may act to 
configure the global system to create a list of files that have been changed that may be 

25 of interest to the IMP's unique processes and may make use of the list to more 
efficiently carry out the IMP's processes. 

The information management process would also be fairly straightforward to 
implement. U^g the knowledge of the virtual directory system, it might be 
configured to communicate with the virtual directory system through its locti or other 
30 such interface. Thus through standard operating system and other commands as well 
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known or readily understood, the IMP can be coordinated to achieve configuration of 
the virtual directory system to emulate any type or arrangement of devices, be they 
real, or virtual. It could also achieve manipulation, storage, and presentation of the 
information from the virtual directoiy system in the manner de^red. 

Fmally the IMPs may be configured as data management applications that 
know how to use the system to their advantage. Most backup packages or archiving 
packages know how to manage files that they have transferred themselves but with a 
per^stent system it could be much easier to share information about where files are 
located between applications. A new type of IMP might be one that pulls digital video 
from your satellite dish and records it to a DVD or tape. Tlus IMP and the PFS then 
can team up to allow you to create your own video library, nicely organized on your 
PC. 

Once the basic principles of the invention are understood, the actual 
implementation of it should be fairly straightfonvard to a person of ordmary skill in the 
art. The currently preferred implementation is as an ancillaiy capability to a standard 
operating system, such as the Windows™ 95 system. As such, by utiliang readily 
available source books for programming, operating systems, and database management 
(such as, the Win 32 DDK, the Win 32 SDK, and the references "Inside Windows™ 
95" by Adrian King as published by Microsoft™ Press, Copyright 1994; "Systems 
Programming for Windows™ 95" by Walter Oney as published by Microsoft™ Press, 
Copyright 1996; and Inside the Wmdows™ 95 File System by Stan Mitchell, 
Copyright 1997 which are hereby incorporated by reference) the software 
embodiments might be accomplished ^thout undue experimentatioit 

As should be readily apparent, the invention might be characterized in a variety 
of dififerent and independent manners. As but one example, the invention might be 
characterized as a system for providing composite memory information comprinng a 
number of elements such as: a processor; a plurality of memory elements responsive to 
said processor, a signal connection through which electronic information can be 
provided between the memory elements and the processor; an interceptor which can 
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access information from the signal connection; a change event sensor responsive to 
said interceptor through which a change event could be determined to adst. In a more 
software sense, it might similarly comprise elements such as: an interceptor routine 
which can access information from said signal connection and a change event sense 
S routme responsive to said interceptor routine through which a change event could be 
determined to exist. 

The discussion included in this patent is intended to serve as a basic 
description. The reader should be aware that the specific discusaon may not explicitly 
describe all embodunents possible; many alternatives are impUcit. Where the invention 

10 is described in method or result-oriented terminology, each function of the invention 
would be achieved by an apparatus element be it hardware- or software-based. 
Apparatus cl^ms may not only be included for the device described, but also method 
or process claims may be included to address the functions the invention and each 
element performs. Equivalent, broader, and more generic terms are implicit in the 

15 prior description of each element. Such terms can be substituted were desired to make 
explicit the implicitly broad coverage to which this invention is entitled. Further, it 
should be understood that a variety of changes may be made without departing from 
the essence of the invention. Such changes are also implicitly included in the 
description. They still fall within the scope of this invention. A broad disclosure 

20 encompassing both the explicit embodiment(s) shown, the great variety of implicit 
alternative embodiments, and the broad methods or processes and the like are 
encompassed by this disclosure. 
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VL CLAIMS 
What is claimed is: 

1) An apparatus to utilize a virtual directory of files on a computer system, 
the apparatus comprising: 

S a) at least one file storage device which stores at least one file for use by the 
computer system; 

b) a native file directory system which provides file attribute information of the at 
least one file storage device; 

c) a virtual file director/ ^stem which provides at least a portion of the file 
10 attribute information of the native file directory system; and 

d) an operating system which is capable of accomplishing input/output procedures 
through the virtual file directory system. 

2) The apparatus to utilize a virtual directory of files on a compute system as 
described in claim 1 and further comprising a means for retrieving a file presented by 

1 5 the virtual directory. 

3) The apparatus to utilize a virtual directory of files on a computer system as 
described in claim 2 and fiirther comprising a means for determining whether a storage 
medium is cormected to the computer system. 

4) The apparatus to utilize a virtual directory of files on a conq)uter system as 
20 described in claim 3 and fiirther comprising a means for prompting a computer 

operator to mount the storage medium. 

5) The apparatus to utilize a virtual directory of files on a computer system as 
described in claun 3 and fiirther comprising a means for automatically mounting the 
storage medium. 
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6) The apparatus to utilize a virtual directory of filos on a compute- system as 
described in claim 3 and further comprising a means for automatically establishing 
connection with a remote storage device. 

7) The lyiparatus to utilize a virtual directory of files on a conq)uter system as 

S described in claim 1 and fiirther con^rising a storage medium vAach can be accessed 
to obtain file attribute information of files stored on the storage medmm. 

8) The apparatus to utilize a virtual directory of files on a computer system as 
described in claim 7and fiirther comprising a means for de^gnating a particular storage 
medium as a medium to monitor for changes to files stored on the particular storage 

10 medium. 

9) The apparatus to utilize a virtual directory of files on a computer system as 
described in claim 7 and fiirther compri^ng a means for monitoring for a mounting of a 
storage medium on the computer system. 

10) The apparatus to utilize a virtual directory of files on a computer system as 
1 S described in claim 9 and fiirther comprising: 

a means for accessing a mounted storage medium; and 

a means for retrieving information about that storage medium. 

1 1) The apparatus to utilize a virtual directory of files on a computer system as 
described in claim 1 and fiirther comprising a means for updating a virtual directory 

20 with changed file attribute information. 

12) The apparatus to utilize a virtual directory of files on a computer system as 
described in claim 1 and fiirther comprising a means for monitoring for changes made 
to the native directory. 

13) The apparatus to utilize a virtual directory of files on a computer ^tem as 
25 described in claim 1 and fiirther comprising a means for presenting a directory of file 
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infonnation for a removable storage medium while the removable storage medium is 
not comiected to the computer system. 

14) The apparatus to utilize a virtual direaory of files on a computer system as 
described in claim 1 and fiirther compri^ng a second virtual directory for use by the 

5 operating system of the computer system. 

15) A method of utilizing a virtual directoiy of files for use by an operating system 
of a computer system, the method comprising: 

a) utilizing a single computer capable of interfacing to a computer system, the 
computer being capable of utilizing a plurality of file storage devices, wherein 

10 at least one of the file storage devices is capable of storing a plurality of files 

and wherein at least one of the files comprises file attribute infonnation; 

b) presenting on the single computer a native directory of at least one of the 
plurality of file storage de\dces utilized by the computer system, such that an 
operating system of the computer system can access a desired file by way of the 

IS native directory; 

c) presenting on the single computer a virtual directory for use by the operating 
system, the virtual directory comprising at least a portion of the file attribute 
infonnation for at least one of the files stored on the plurality of file storage 
devices; 

20 wherein the operating system can access through the virtual directory files represented 
by the file attribute information on the virtual directory. 

16) The method of utilizing a virtual directory of files as described in claim IS 
wherein the virtual directoiy is accessible by an application progrant 

17) The method of utilizing a virtual directory of files as described in claim IS and 
25 fiirther comprising: 
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accepting a command for a file presented by the virtual diiectoor, and 
causing retrieval of the file presented by the virtual directory. 



18) The method of utilizing a virtual directory of files as described in claim 17 and 
5 fiirther comprising determining whether a storage medium is connected to the 

computer system. 

19) The method of utilizing a virtual directory of files as described in claim 18 and 
fiirther comprising prompting a computer operator to mount the storage 
medium if the storage medium is not mounted. 

10 20) The method of utilizing a virtual directory of files as described in claim 1 8 and 
fiirther comprising automatically mounting the storage medium. 

21) The method of utilizmg a virtual directoiy of files as described in claun 18 and 
fiirther comprising automatically establishing a connection with a remote 
storage device. 

15 22) The method of utiliang a virtual directory of files as described in claim 15 and 
fiirther comprising: 

storing a file on at least one of the plurality of storage devices; and 
storing file attribute information of the file on the virtual directoiy. 

23) The method of utilizing a virtual durectory of files as described in claim 15 and 
20 fiirther comprismg accessing a storage medium to obtain file attribute 

information of files stored on the storage medium. 

24) The method of utilizing a virtual directory of files as described in claim 15 and 
fiirther comprising querymg a computer operator whether file attribute 
information for a piece of storage media should be added to the vutual 
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directory. 

25) The method of utilizing a virtual directory of files as described in claim 23 and 
further comprising designating a particular storage medium as a medium to 
monitor for changes to files stored on the particular storage medium. 

26) The method of utilizing a virtual directory of files as described in claim 25 and 
fiirther comprising providing to the computer operator a list of storage media 
available to be monitored. 

27) The method of utilizing a virtual directory of files as described in claim 26 and 
fiirther comprising displaying a list of storage media bdng monitored. 

28) The method of utilizing a virtual directory of files as described in claim 26 and 
fiirther compri^g displaying a list of storage media not bdng monitored. 

29) The method of utiliang a virtual directory of files as described in claim 15 or 
23 and fiirther comprising monitoring for a mounting of a storage medium on 
the computer system. 

30) The method of utiliang a virtual directory of files as described in claim 29 and 
fiirther comprising: 

accessing a mounted storage medium; and 

retrieving information about that storage medium for storage on the virtual 
cUrectory. 

3 1) The method of utilizirig a virtual directory of files as described in claim 30 and 
fiirther comprising checking whether the mounted storage medium should be 
monitored. 

32) The method of utili:ring a virtual directory of files as described in claim 3 1 and 
fiirther comprising checking whether any changes have been made to the 
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mounted storage medium ^nce the mounted storage medium was removed 
from the computer system. 

33) The method of utilizing a virtual directory of files as described in claun 32 and 
further comprising updating the virtual directory with changed file attribute 

S information from the storage medium. 

34) The method of utilizing a virtual directoiy of files as described in claim IS and 
fiirther comprising monitoring for changes made to the native directory. 

35) The method of utiliang a virtual directory of files as described in claim 34 and 
fiirther comprising monitoring for input/output commands to know when file 

10 changes occur. 

36) The method of utilizing a virtual directory of files as described in claim 15 or 
34 and fiirther comprising monitoring for a new file saved to the native 
directory. 

37) The method of utiliang a virtual directory of files as described in claim 15 or 
IS 35 and fiirther comprising monitoring for a new version of a file saved to the 

native directory. 

38) The method of utilizing a virtual directory of files as described in claim 36 and 
fiirther comprising updating the virtual directory with file attribute information 
for the new file. 

20 39) The method of utilizing a virtual directory of files as described in claim 37 and 
fiirther comprising updatmg the virtual directory with file attribute information 
for the new versioa 

40) The method of utilizing a virtual directory of files as described in claim 15 and 
fiirther comprising monitoring for a command to open a file. 

25 4 1) The method of utilizing a virtual directory of files as described in claim 40 and 
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fiirther comprising: 

associating a file handle with a file retrieved fi-om the native directoiy; 

monitoring for the file handle to know when a revised file is being stored to the 
native directory; 

5 capturing file attribute information for the revised file; and 

storing the file attribute information in the virtual directoiy. 

42) The method of utilizing a virtual directory of files as described in claim IS and 
fiirther comprising presenting a directory of file information for a remo^le 
storage medium while the removable storage medium is not connected to the 

10 computer system. 

43) The method of utilizing a virtual directory of files as described in claim 42 and 
fiirther comprising receiving requests for a file stored on the removable storage 
medium which is not connected to the computer system. 

44) The method of utiliang a virtual directory of files as described in claim 42 and 
IS fiirther comprising automatically connecting the removable storage medium to 

the computer system. 

45) The method of utilizing a virtual directory of files as described in claim 42 and 
fiirther comprising prompting the compute operator to coimect the removable 
storage medium to the compute- system. 

20 46) The method of utilising a virtual directory of files as described in claim IS and 
fiirther comprising presenting a second virtual directory for use by the 
operating systent 

47) The method of utilizing a virtual directory of files as described in claim IS and 
fiirther comprising: 
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receiving an open file command directed to the virtual file directory, wherdn 
the file data requested is stored on a storage medium; and 

cau^g the file data stored on the storage medium to be opened. 

48) The method of utilizing a virtual directoiy of files as described in claim IS and 
S further comprising: 

receiving an open file command directed to the virtual file directory for a file 
represented on the virtual directory but stored on a storage medium; 

initiating an open file command directed to the storage medium for the file 
represented on the virtual directory; and 

10 reading the file fi-om the storage medium. 

49) The method of utiliang a virtual directoiy of files as described in daim IS and 
fiirther comprising: 

receiving a save file command directed to the virtual file ^stem for a file to be 
represented on the virtual directory; 

1 S initiating a save file command directed to a storage medium where the file is to 

be stored; and 

storing the file on the storage medium. 

50) The method of utili^ng a virtual directory of files as described in claim IS and 
fiirther comprising presenting the virtual directoiy in a hierarchical manner. 

20 SI) The method of utilizing a virtual directory of files as described in claim 1 S and 
fiirther comprising: 

entering a file name to be retrieved fi-om the virtual directory; 
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determining which storage medium stores file data for the file name; and 
retrieving the file data. 

52) The method of utilizing a virtual directory of files as described in claim IS and 
further comprising: 

S maintaining file attribute information about at least one file not connected to 

the computer system; and 

presenting the file attribute information of the at least one file not connected to 
the computer system as a part of the virtual directory. 

53) The method of utilizing a virtual directory of files as described in claim IS and 
10 fiirther comprising: 

presenting a first file having a file name in the virtual directory; and 

presenting a second file having the same file name in the virtual directoiy. 

54) An apparatus to update a file directory in a computer system, the apparatus 
comprising: 

IS a) a native hierarchical file directory of the computer system comprising file 
attribute information; 

b) a second file directory having a non-hierarchical directory; 

c) a portion of the file attribute information of the native file directory stored in 
the second file directory 

20 d) a means for monitoring input/output procedures directed toward the native file 
directory to intercept information about changes made to files on the native file 
directory; 
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e) a means for rela^g the intorcepted information about changes made to files on 
the native file directory to the second file directory; and 

0 a storage medium on which to store the intercepted information. 

55) The apparatus to update a file directory in a computer system as described in 
5 claim 54 and further comprising: 

a means for scanning the native file directory to detect directory information of 
the native file directory to relay to the second file directory. 

56) The apparatus to update a file directory in a computer system as described in 
claim 54 and further comprising a means for linking with I/O procedures of the native 

10 file system to intercept changes to the native file system. 

57) The apparatus to update a file directory in a computer system as described in 
daim 54 and further comprising a means for monitoring I/O requests fi-om an 
application program directed toward the native file directory. 

58) The apparatus to update a file directory in a computer system as described in 
1 5 claim 54 and further comprising a means for monitoring for VO requests from the 

operating system of the computer system directed toward the native file directory. 

59) The apparatus to update a file directory in a computer ^stem as described in 
claim 54 and further comprising: 

a means for copying file path information for a file being stored on the native 
20 file directory; and 

a means for relaying the file path information to the second file system. 

60) The apparatus to update a file directory, in a computer system as described in 
chum 54 and further comprising: 

a means for checking time stamp information for a file on a removable storage 
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medium against a last recorded time stamp for a file having the same file name as that 
file on the second file directory. 

61) The apparatus to update a file directory in a computer system as described in 
claim S4and further comprising a means fi^r capturing an application program name 

S that originates a file request command. 

62) A method of updating a file directory in a computer system, the computer 
system ha^ong a native hierarchical file directory and input/output procedures for the 
input/output of files on the native hierarchical file directory, the method comprising: 

a) utilizing a native hierarchical file directory comprismg file attribute information; 

10 b) utilizing a second file directory having a non-hierarchical directory, the second 
file directory comprismg at least a portion of the file attribute information of 
the native file directory; 

c) monitoring input/output procedures directed toward the native file directory to 
intercept information about changes made to files on the native file directory; 

IS d) relaying the intercepted information about changes made to files on the native 
file directory to the second file directory; 

e) saving the intercq}ted information in the second file directory. 



20 63) The method of updating a file directory in a computer system as described in 
claim 62 and further comprising scanning the native file directory and relaying 
directory information of the native file ^rectory to the second file directory. 

64) The method of updating a file directory in a computer system as described in 
daim 62 and further compri^ng linking with the I/O procedures of the native 
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file system to intercept changes made to the native file system. 

65) The method of updating a file directory in a computer system as described in 
daim 62 and fiuther comprising monitoring for I/O requests fi'om an 
application program directed toward the native file directory. 

66) The method of updating a file directory in a computer system as described in 
claim 62 and fiirther comprising monitoring for I/O requests fi'om the operating 
system of the computer ^tem directed toward the native file cfirectory. 

67) The method of updating a file directory in a computer system as described in 
claim 62 and fiirther comprising: 

copying file path information for a file being stored on the native file directorjr, 

and 

relaying the file path information to the second file system. 

68) The method of updating a file directory in a computer system as described in 
claim 62 and fiirther compri^ng monitoring for a mounting of a removable 
storage medium to the computer system. 

69) The method of updating a file directory in a computer system as described in 
daim 68 and fiirther comprising determining whether the storage medium has 
been connected to the computer system before. 

70) The method of updating a file directory in a conq>uter system as described in 
claim 69 and fiirther comprising: 

reading the label of the removable storage medium; 

quafying the second directory to see if file attribute data of the removable 
storage medium has been previously recorded with the second directory. 

71) The method of updating a file directory in a computer system as described in 
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daim 69 and further comprising adding file information fi^om the removable 
storage medium to the second directoiy . 

72) The method of updating a file directoiy in a conq>uter systrni as described in 
daim 69 and fiirther comprising updating on the second directoiy old file 

S information for a file with new file information. 

73) The method of updating a file directory in a computer system as described in 
claim 62 and fiirther comprising polling a phyacal storage devices which can 
house removable media to determine whether a piece of removable media has 
been installed. 

10 74) The method of updating a file directoiy in a computer system as described in 
daim 73 and fiirther comprising checking time stamp information for a file on 
the removable medium against a last recorded time stamp for that file on the 
second file directory. 

75) The method of updating a file directory in a computer system as described in 
15 daim 62 detecting a media change message fiom a file system driver. 

76) The method of updating a file directory in a computer system as described in 
daim 62 and fiirther comprising: 

capturing an application program name that originates a file request. 

77) A computer system comprising: 
20 a) an accessible native file directory; 

b) a configurable file database presentable as a virtual directory to store file 
attribute data; 

c) a minimum number of file attribute fields of the configurable file database for 
storing file attribute information; and 
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wherein the configurable file database can be configured to have additional file 
attribute fields to store additional file attribute information vAiSle maintaimng the 
accessibility of the accessible native file directory. 

78) The computer system as described in claim 77 and fiirther comprising a means 
S for adcfing a new file attribute to the configurable file database. 

79) The computer system as desoibed in claim 77 and fiirther comprising: 
a means for selecting a file attribute field; and 

a means for sorting the configurable file database based on a selected file 
attribute field. 

10 80) The computer system as described in claim 77 and fiirther comprising: 

a means for deleting a file attribute field 

81) The computer system as described in claim 77 and fiirther conq)rimg and 
fiirther comprising a means for sorting the configurable file database based on a 
selected file attribute field into a first virtual directory. 

1 5 82) The computer system as described in claim 8 1 and fiirther compridng a means 
for sorting the configurable file database based on a second selected file attribute field 
into a second virtual directcny. 

83) The computer system as described in claim 77 and wherdn at least two files 
having the same file name are listed in the configurable file database. 

20 84) A method of creating a non-hierarchical file directory for use by a computer 
having a native hierarchical file dlrectoiy, the method comprising: 

a) establishing an accessible native file directory on the computen 

b) configuring a file database to have a first maximum number of file attribute 
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fields; 

c) reconfiguring the file database to have a second maximum number of file 
attribute fields greater than the first maximum number of file attribute fields, 
the first maximum number of file attribute fields being adjustable after the 

S creation of the non-hierarchical file directory; wlule 

d) maintaining the accessibility of the native file directory system after 
reconfiguring the file database. 

85) The method of updating a file directory in a computer system as described in 
claim 84 and fiirther comprising adding a new file attribute to a file database. 

10 86) The method of updating a file directory in a computer system as described in 
claim 84 and fiirther comprising: 

selecting a file attribute field; and 

sorting the file database based on the selected file attribute field. 

87) The method of updating a file directory in a computer system as described in 
1 S claim 86 and fiirther comprising presenting the sorted database. 

88) The method of updating a file directory in a computer system as described in 
daim 84 and fiirther comprising: 

ddeting a file attribute field fi^om the file database; and 

presenting the database. 

20 89) The method of updating a file directory in a computer system as described in 
claim 84 and fiirther comprising: 

selecting a file attribute field; 
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sorting the file database into a first group of files based on the selected file 
attribute field; and 

presenting the first group of files in a first virtual directory. 

90) The method of updating a file directory in a computer system as described in 
5 claim 89 and fiirther comprising: 

selecting a second file attribute field; 

sorting the file database into a second group of files based on the second file 
attribute field; 

presenting the second group of files in a second virtual directory. 

10 91) The method of updating a file directory in a computer system as described in 
claim 84 and fiirther comprising utilizing time stamp information to maintam at 
least two files having same the same filename but different time stamp 
information in same file database. 



92) An apparatus compri^g: 
15 a) a native file directory for storing directory information; 

b) a virtual file directory capable of storing at least a portion of the directory 
information stored on the native file directory; 

c) a private interface coupled to the virtual file directory which is capable of 
communicating commands to the virtual file directory. 

20 93) The apparatus as described in claim 92 and further comprising a means for 
sorting the virtual file directory based on user criteria input by a computer operator. 

94) The apparatus as described in claim 93 and fiirther comprising a filter to filter 
file information stored on a database of the virtual file directory. 



58 



wo 98/24025 



PCT/US97/21837 



95) The apparatus as described in claim 92 and fiirther comprising a second virtual file 
directory. 

96) The apparatus as described in claim 95 wherein the virtual file directoiy and the 
second virtual file directory are accessible to an application program of the computer 



97) The apparatus as described in claim 96 and fijrther comprising a means for 
reconfiguring the ^drtual file directoiy. 

98) The apparatus as described in claim 92 and fixrther comprising a means for 
redefining the hierarchy of the virtual file directory after a first hierarchy of the virtual 

10 file directory is established. 

99) The apparatus as described m claim 92 and fiirther comprising a storage 
medium on which to store a file represented on the virtual file directory in order to 
backup the file. 

100) A method of utilizing a virtual file directory for a computer system, the 

15 computer system having a native file directory comprising directoiy information, the 
method comprising: 

a) inputting to the virtual file directory at least a portion of the directory 
information stored on the native file directory; 

b) utiliang a database to store the portion of directory information in the virtual 
20 file directory; and 

c) issumg a command to the database by way of a private inter&ce to the virtual 
file directory. 

101) The method of utilizing a virtual file directory fi>r a computer system as 
described in claim 100 and fiirther comprising managing the database based on 

25 the command issued to the database by way of the private interfiioe. 
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102) The method of utilizing a virtual file directoiy for a computer system as 
described in claim 100 and further comprising: 

inputting user criteria for sorting of file information stored in the database; and 

sorting the file information based on the input user criteria. 

5 103) The method of utilizing a virtual file directory for a computer system as 
described in claim 102 and fiirther comprising utilizing a filter to filter the file 
information in the database. 

104) The method of utilizing a virtual file directory for a computer system as 
described in claim 100 and further comprising: 

10 sorting the virtual file directory; 

presenting a first grqup of file information stored in the database in a first 
virtual directory 

presenting a second group of file information stored in the database in a second 
virtual directoiy; and 

1 5 makuig the first virtual directoiy and second virtual directory accessible to the 
operating system of the computer system. 



105) The method of utilizing a virtual file directory for a computer system as 
described in claim 100 and further comprising: 

20 sorting the virtual file directoiy; 

presenting a first group of file information stored in the database in a first 
virtual directory. 
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presenting a second group of file information stored in the database in a second 
virtual directory; and 

making the first virtual directoiy and second ^rtual directory accessible to an 
application program of the computer system. 

5 106) The method of utilizing a virtual file directory for a computer system as 
described in claim lOS wherdn the application program reconfigures the 
virtual file directory. 

107) . The method of utilizing a virtual file directory for a computer system as 

described in claim 100 and further comprising redefining a hierarchy of the 
10 virtual file directory after a first hierarchy of the virtual file directory is 

established. 

108) The method of utilizing a virtual file directory for a computer system as 
described in claim 100 and fiirth^ comprising presenting a native file directory 
in addition to the virtual file directoiy for use by an operating system of the 

IS computer system. 

109) The method of utilizing a virtual file directory for a computer system as 
described in claim 100 and fiirther comprising storing a file represented on the 
virtual file directory to a storage device in order to backup the file. 
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